IRIX Base Documentation 2002 November

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / a_man / cat1 / mtrace.z / mtrace

Wrap

Text File | 2002-10-03 | 21.0 KB | 397 lines

MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) NNNNAAAAMMMMEEEE mtrace - print multicast path from a source to a receiver SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS ////uuuussssrrrr////eeeettttcccc////mmmmttttrrrraaaacccceeee [ ----gggg _g_a_t_e_w_a_y ] [ ----iiii _i_f__a_d_d_r ] [ ----llll ] [ ----MMMM ] [ ----mmmm _m_a_x__h_o_p_s ] [ ----nnnn ] [ ----pppp ] [ ----qqqq _n_q_u_e_r_i_e_s ] [ ----rrrr _r_e_s_p__d_e_s_t ] [ ----ssss ] [ ----tttt _t_t_l ] [ ----wwww _w_a_i_t_t_i_m_e ] _s_o_u_r_c_e [ _r_e_c_e_i_v_e_r ] [ _g_r_o_u_p ] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN Assessing problems in the distribution of IP multicast traffic can be difficult. mmmmttttrrrraaaacccceeee utilizes a tracing feature implemented in multicast routers (mmmmrrrroooouuuutttteeeedddd version 3.3 and later) that is accessed via an extension to the IGMP protocol. A trace query is passed hop-by-hop along the reverse path from the _r_e_c_e_i_v_e_r to the _s_o_u_r_c_e, collecting hop addresses, packet counts, and routing error conditions along the path, and then the response is returned to the requestor. The only required parameter is the _s_o_u_r_c_e host name or address. The default _r_e_c_e_i_v_e_r is the host running mtrace, and the default _g_r_o_u_p is "MBone Audio" (224.2.0.1), which is sufficient if packet loss statistics for a particular multicast group are not needed. These two optional parameters may be specified to test the path to some other receiver in a particular group, subject to some constraints as detailed below. The two parameters can be distinguished because the _r_e_c_e_i_v_e_r is a unicast address and the _g_r_o_u_p is a multicast address. OOOOPPPPTTTTIIIIOOOONNNNSSSS ----gggg _g_w_y Send the trace query via unicast directly to the multicast router _g_w_y rather than multicasting the query. This must be the last- hop router on the path from the intended _s_o_u_r_c_e to the _r_e_c_e_i_v_e_r. _C_A_U_T_I_O_N!! Version 3.3 of mmmmrrrroooouuuutttteeeedddd will crash if a trace query is received via a unicast packet and mmmmrrrroooouuuutttteeeedddd has no route for the _s_o_u_r_c_e address. Therefore, do not use the ----gggg option unless the target mmmmrrrroooouuuutttteeeedddd has been verified to be newer than 3.3. ----iiii _a_d_d_r Use _a_d_d_r as the local interface address (on a multi-homed host) for sending the trace query and as the default for the _r_e_c_e_i_v_e_r and the response destination. ----llll Loop indefinitely printing packet rate and loss statistics for the multicast path every 10 seconds. ----MMMM Always send the response using multicast rather than attempting unicast first. ----mmmm _n Set to _n the maximum number of hops that will be traced from the _r_e_c_e_i_v_e_r back toward the _s_o_u_r_c_e. The default is 32 hops (infinity for the DVMRP routing protocol). PPPPaaaaggggeeee 1111 MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) ----nnnn Print hop addresses numerically rather than symbolically and numerically (saves a nameserver address-to-name lookup for each router found on the path). ----qqqq _n Set the maximum number of query attempts for any hop to _n. The default is 3. ----pppp Listen passively for multicast responses from traces initiated by others (not implemented yet). ----rrrr _h_o_s_t Send the trace response to _h_o_s_t rather than to the host on which mmmmttttrrrraaaacccceeee is being run, or to a multicast address other than the one registered for this purpose (224.0.1.32). ----ssss Print a short form output including only the multicast path and not the packet rate and loss statistics. ----tttt _t_t_l Set the _t_t_l (time-to-live, or number of hops) for multicast trace queries and responses. The default is 64, except for local queries to the "all routers" multicast group which use ttl 1. ----wwww _n Set the time to wait for a trace response to _n seconds (default 3 seconds). UUUUSSSSAAAAGGGGEEEE HHHHoooowwww IIIItttt WWWWoooorrrrkkkkssss The technique used by the ttttrrrraaaacccceeeerrrroooouuuutttteeee tool to trace unicast network paths will not work for IP multicast because ICMP responses are specifically forbidden for multicast traffic. Instead, a tracing feature has been built into the multicast routers. This technique has the advantage that additional information about packet rates and losses can be accumulated while the number of packets sent is minimized. Since multicast uses reverse path forwarding, the trace is run backwards from the _r_e_c_e_i_v_e_r to the _s_o_u_r_c_e. A trace query packet is sent to the last hop multicast router (the leaf router for the desired _r_e_c_e_i_v_e_r address). The last hop router builds a trace response packet, fills in a report for its hop, and forwards the trace packet using unicast to the router it believes is the previous hop for packets originating from the specified _s_o_u_r_c_e. Each router along the path adds its report and forwards the packet. When the trace response packet reaches the first hop router (the router that is directly connected to the source's net), that router sends the completed response to the response destination address specified in the trace query. If some multicast router along the path does not implement the multicast traceroute feature or if there is some outage, then no response will be returned. To solve this problem, the trace query includes a maximum hop count field to limit the number of hops traced before the response is returned. That allows a partial path to be traced. PPPPaaaaggggeeee 2222 MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) The reports inserted by each router contain not only the address of the hop, but also the ttl required to forward and some flags to indicate routing errors, plus counts of the total number of packets on the incoming and outgoing interfaces and those forwarded for the specified _g_r_o_u_p. Taking differences in these counts for two traces separated in time and comparing the output packet counts from one hop with the input packet counts of the next hop allows the calculation of packet rate and packet loss statistics for each hop to isolate congestion problems. FFFFiiiinnnnddddiiiinnnngggg tttthhhheeee LLLLaaaasssstttt----HHHHoooopppp RRRRoooouuuutttteeeerrrr The trace query must be sent to the multicast router which is the last hop on the path from the _s_o_u_r_c_e to the _r_e_c_e_i_v_e_r. If the receiver is on the local subnet (as determined using the subnet mask), then the default method is to multicast the trace query to all-routers.mcast.net (224.0.0.2) with a ttl of 1. Otherwise, the trace query is multicast to the _g_r_o_u_p address since the last hop router will be a member of that group if the receiver is. Therefore it is necessary to specify a group that the intended receiver has joined. This multicast is sent with a default ttl of 64, which may not be sufficient for all cases (changed with the ----tttt option). If the last hop router is known, it may also be addressed directly using the ----gggg option). Alternatively, if it is desired to trace a group that the receiver has not joined, but it is known that the last-hop router is a member of another group, the ----gggg option may also be used to specify a different multicast address for the trace query. When tracing from a multihomed host or router, the default receiver address may not be the desired interface for the path from the source. In that case, the desired interface should be specified explicitly as the _r_e_c_e_i_v_e_r. DDDDiiiirrrreeeeccccttttiiiinnnngggg tttthhhheeee RRRReeeessssppppoooonnnnsssseeee By default, mmmmttttrrrraaaacccceeee first attempts to trace the full reverse path, unless the number of hops to trace is explicitly set with the ----mmmm option. If there is no response within a 3 second timeout interval (changed with the ----wwww option), a "*" is printed and the probing switches to hop-by-hop mode. Trace queries are issued starting with a maximum hop count of one and increasing by one until the full path is traced or no response is received. At each hop, multiple probes are sent (default is three, changed with ----qqqq option). The first half of the attempts (default is one) are made with the unicast address of the host running mmmmttttrrrraaaacccceeee as the destination for the response. Since the unicast route may be blocked, the remainder of attempts request that the response be multicast to mtrace.mcast.net (224.0.1.32) with the ttl set to 32 more than what's needed to pass the thresholds seen so far along the path to the receiver. For the last quarter of the attempts (default is one), the ttl is increased by another 32 each time up to a maximum of 192. Alternatively, the ttl may be set explicitly with the ----tttt option and/or the initial unicast attempts can be forced to use multicast instead with the ----MMMM option. For each attempt, if no response is received within the timeout, a "*" is printed. After the specified number of attempts have failed, mmmmttttrrrraaaacccceeee will try to query the next hop router with a DVMRP_ASK_NEIGHBORS2 request (as used by the mmmmrrrriiiinnnnffffoooo program) to see what kind of router it is. PPPPaaaaggggeeee 3333 MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS The output of mmmmttttrrrraaaacccceeee is in two sections. The first section is a short listing of the hops in the order they are queried, that is, in the reverse of the order from the _s_o_u_r_c_e to the _r_e_c_e_i_v_e_r. For each hop, a line is printed showing the hop number (counted negatively to indicate that this is the reverse path); the multicast routing protocol (DVMRP, MOSPF, PIM, etc.); the threshold required to forward data (to the previous hop in the listing as indicated by the up-arrow character); and the cumulative delay for the query to reach that hop (valid only if the clocks are synchronized). This first section ends with a line showing the round-trip time which measures the interval from when the query is issued until the response is received, both derived from the local system clock. A sample use and output might be: oak.isi.edu 80# mtrace -l caraway.lcs.mit.edu 224.2.0.3 Mtrace from 18.26.0.170 to 128.9.160.100 via group 224.2.0.3 Querying full reverse path... 0 oak.isi.edu (128.9.160.100) -1 cub.isi.edu (128.9.160.153) DVMRP thresh^ 1 3 ms -2 la.dart.net (140.173.128.1) DVMRP thresh^ 1 14 ms -3 dc.dart.net (140.173.64.1) DVMRP thresh^ 1 50 ms -4 bbn.dart.net (140.173.32.1) DVMRP thresh^ 1 63 ms -5 mit.dart.net (140.173.48.2) DVMRP thresh^ 1 71 ms -6 caraway.lcs.mit.edu (18.26.0.170) Round trip time 124 ms The second section provides a pictorial view of the path in the forward direction with data flow indicated by arrows pointing downward and the query path indicated by arrows pointing upward. For each hop, both the entry and exit addresses of the router are shown if different, along with the initial ttl required on the packet in order to be forwarded at this hop and the propagation delay across the hop assuming that the routers at both ends have synchronized clocks. The right half of this section is composed of several columns of statistics in two groups. Within each group, the columns are the number of packets lost, the number of packets sent, the percentage lost, and the average packet rate at each hop. These statistics are calculated from differences between traces and from hop to hop as explained above. The first group shows the statistics for all traffic flowing out the interface at one hop and in the interface at the next hop. The second group shows the statistics only for traffic forwarded from the specified _s_o_u_r_c_e to the specified _g_r_o_u_p. These statistics are shown on one or two lines for each hop. Without any options, this second section of the output is printed only once, approximately 10 seconds after the initial trace. One line is shown for each hop showing the statistics over that 10-second period. If the ----llll option is given, the second section is repeated every 10 seconds and two lines are shown for each hop. The first line shows the statistics for the last 10 seconds, and the second line shows the cumulative statistics over the period since the initial trace, which is 101 seconds in the example below. The second section of the output is omitted if the ----ssss option is set. PPPPaaaaggggeeee 4444 4444 MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) Waiting to accumulate statistics... Results after 101 seconds: Source Response Dest Packet Statistics For Only For Traffic 18.26.0.170 128.9.160.100 All Multicast Traffic From 18.26.0.170 | __/ rtt 125 ms Lost/Sent = Pct Rate To 224.2.0.3 v / hop 65 ms --------------------- ------------------ 18.26.0.144 140.173.48.2 mit.dart.net | ^ ttl 1 0/6 = --% 0 pps 0/2 = --% 0 pps v | hop 8 ms 1/52 = 2% 0 pps 0/18 = 0% 0 pps 140.173.48.1 140.173.32.1 bbn.dart.net | ^ ttl 2 0/6 = --% 0 pps 0/2 = --% 0 pps v | hop 12 ms 1/52 = 2% 0 pps 0/18 = 0% 0 pps 140.173.32.2 140.173.64.1 dc.dart.net | ^ ttl 3 0/271 = 0% 27 pps 0/2 = --% 0 pps v | hop 34 ms -1/2652 = 0% 26 pps 0/18 = 0% 0 pps 140.173.64.2 140.173.128.1 la.dart.net | ^ ttl 4 -2/831 = 0% 83 pps 0/2 = --% 0 pps v | hop 11 ms -3/8072 = 0% 79 pps 0/18 = 0% 0 pps 140.173.128.2 128.9.160.153 cub.isi.edu | \__ ttl 5 833 83 pps 2 0 pps v \ hop -8 ms 8075 79 pps 18 0 pps 128.9.160.100 128.9.160.100 Receiver Query Source Because the packet counts may be changing as the trace query is propagating, there may be small errors (off by 1 or 2) in these statistics. However, those errors should not accumulate, so the cumulative statistics line should increase in accuracy as a new trace is run every 10 seconds. There are two sources of larger errors, both of which show up as negative losses: +o If the input to a node is from a multi-access network with more than one other node attached, then the input count will be (close to) the sum of the output counts from all the attached nodes, but the output count from the previous hop on the traced path will be only part of that. Hence the output count minus the input count will be negative. +o In release 3.3 of the DVMRP multicast forwarding software for SunOS and other systems, a multicast packet generated on a router will be counted as having come in an interface even though it did not. This creates the negative loss that can be seen in the example above. Note that these negative losses may mask positive losses. PPPPaaaaggggeeee 5555 MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) MMMMTTTTRRRRAAAACCCCEEEE((((1111MMMM)))) In the example, there is also one negative hop time. This simply indicates a lack of synchronization between the system clocks across that hop. This example also illustrates how the percentage loss is shown as two dashes when the number of packets sent is less than 10 because the percentage would not be statistically valid. A second example shows a trace to a receiver that is not local; the query is sent to the last-hop router with the ----gggg option. In this example, the trace of the full reverse path resulted in no response because there was a node running an old version of mmmmrrrroooouuuutttteeeedddd that did not implement the multicast traceroute function, so mmmmttttrrrraaaacccceeee switched to hop-by-hop mode. The "Route pruned" error code indicates that traffic for group 224.2.143.24 would not be forwarded. oak.isi.edu 108# mtrace -g 140.173.48.2 204.62.246.73 \ butter.lcs.mit.edu 224.2.143.24 Mtrace from 204.62.246.73 to 18.26.0.151 via group 224.2.143.24 Querying full reverse path... * switching to hop-by-hop: 0 butter.lcs.mit.edu (18.26.0.151) -1 jam.lcs.mit.edu (18.26.0.144) DVMRP thresh^ 1 33 ms Route pruned -2 bbn.dart.net (140.173.48.1) DVMRP thresh^ 1 36 ms -3 dc.dart.net (140.173.32.2) DVMRP thresh^ 1 44 ms -4 darpa.dart.net (140.173.240.2) DVMRP thresh^ 16 47 ms -5 * * * noc.hpc.org (192.187.8.2) [mrouted 2.2] didn't respond Round trip time 95 ms AAAAUUUUTTTTHHHHOOOORRRR Implemented by Steve Casner based on an initial prototype written by Ajit Thyagarajan. The multicast traceroute mechanism was designed by Van Jacobson with help from Steve Casner, Steve Deering, Dino Farinacci, and Deb Agrawal; it was implemented in mmmmrrrroooouuuutttteeeedddd by Ajit Thyagarajan and Bill Fenner. The option syntax and the output format of mmmmttttrrrraaaacccceeee are modeled after the unicast ttttrrrraaaacccceeeerrrroooouuuutttteeee program written by Van Jacobson. SSSSEEEEEEEE AAAALLLLSSSSOOOO mmmmrrrroooouuuutttteeeedddd(1m),,,, ttttrrrraaaacccceeeerrrroooouuuutttteeee(1m) PPPPaaaaggggeeee 6666